While we at OUJS do have meta.js your implementation is incorrect. Modern .user.js managers already support these automatically so technically they can be omitted.

Target code:

// @updateURL   https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Thanks.

You appear to have this issue on multiple scripts as well.

Hi Marti, thanks for the notification, but what do you mean with "your implementation is incorrect"? Is there anything actually wrong?

I know that @updateURL could be omitted, but I thought I'd include it since I'm also hosting my scripts on GitHub where no meta.js is available. If a user therfore installs it from GitHub I had hoped updates would automatically be pulled from OUJS?

P.S.: I'm sure you already know, but Greasy Fork strips @updateURL and @downloadURL for uploaded scripts, so scripts are always pulled from Greasy Fork. Might be worth a though for OUJS, too.

Re: @Ede_123:

strips @updateURL and @downloadURL for uploaded scripts

Different and questionable methodology that OUJS doesn't support nor any of the known .user.js engines. OUJS attempts to offer the same choices that the engines do instead of no choice.

I had hoped updates would automatically be pulled from OUJS?

If you want to force update checks, or consolidate, from OUJS (or another site) you can specify it manually. The .user.js engines default from whatever site it is installed from, which that methodology is demonstrated at oujs - Meta View, and that breadcrumb trail leads to #105 (comment) for the manual route (a.k.a the @updateURL).

GitHub where no meta.js is available

Some authors create one manually or with script processing before committing to GH to make one.

The choice is yours on how to handle this correctly. Just thought I'd pipe in that I saw you were assuming USO standards not OUJS... and breaking updates with all .user.js engines that support updating e.g. your users won't get updates on a url that returns 404 from us. :)

Re: @Marti:

I still don't get why this should break anything? I just reinstalled the script from GitHub (https://github.com/Ede123/userscripts/raw/master/OpenSubtitles_Direct_Downloads.user.js) and it updates just fine!
It's pulling the meta.js from https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js with an header "accept" value of "text/x-userscript-meta" and receives the meta data just fine.

So what is wrong with explicitly specifying the meta URL in the script? There is no 404 error at my end...

After a long struggle I think I finally understand what you wanted to tell me in the first place:
// @updateURL https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js
is unnecessary, since it's automatically used if the download URL was
https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.user.js

Even if I want my scripts to force to update from OUJS (despite being installed from e.g. GitHub) it's sufficient to specify
// @downloadURL https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.user.js
Since this will set the update URL accordingly.

I'd only need @updateURL if I wanted the update URL to be completely different from the install URL (e.g. if I wanted script updates to be always pulled from GitHub while having update checking handled via OUJS).

Did I get it right now? ;-)

Re: @Ede_123:

It's pulling the meta.js from https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Have you actually tried clicking that link directly? GM and other engines will use that and it 404's because you didn't use the OUJS form, which for this script is:

https://openuserjs.org/meta/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Some of the engines fallback on error to the install path, in OUJS case that would be https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.user.js ... so you aren't using the update mechanism in some engines and making your users use full source instead of meta.js... thus you are breaking the update mechanism. Not to mention if the engine isn't smart enough to store the failure and never request it again... e.g. generating more traffic than may be necessary. On any engine that doesn't support the request header, e.g. older GM versions for example, you are sending out a request that fails to update.

All of this is usually why it's recommended to let the engine handle it to avoid confusion. Consolidation is okay and a feature available but if you want OUJS to handle it for GH installs... then you need to use the proper route (path) to the meta.js routine. :) Does this all make more sense now?

Re: @Marti:

Yes, it's clear to me now, why it's much better to leave out the @updateURL or point it to the correct /meta/ subpage.

However you had me constantly confused with mentioning the 404 on the /install/ subpages. Since with the correct request header (Accept: text/x-userscript-meta) those work nicely (equally for .meta.js and .user.js), and that's what Greasemonkey was doing for me all along. I understand however, that not all engines actually support this header.

Is there somewhere an overview which engines (also outdated ones) supported which update mechanisms with what kinds of fallback chains?
E.g. if I create a "meta.js" on GitHub (where no specific request headers are supported) in the same location as the user.js, will this work for all engines equally well? Or will I run into any problems if I completely leave out @updateURL and @installURL?
I don't need to have my script installs/updates consolidated, I just want to make sure that it works equally well everywhere with correct update checks.

I updated my scripts now (removed @updateURL and @installURL completely) but in the end Grease Monkey continues to update from e.g.

https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

I really don't know what all the fuss was about... On my system the difference is basically zero given Grease Monkey's update handling.